A related copending application (Ser. No. 08/537,648) teaches and claims an information handling system, method and article of manufacture for automatically inserting object services such as persistence, concurrency, recoverability, security and distribution into binary classes in an information handling system employing object oriented technology. The related invention includes registering a description of a class in a name service context, and searching the name service context for a class object referred to as a factory, among other elements of the invention.
Another related copending application (Ser. No. 08/554,063) teaches and claims an information handling system, method and article of manufacture for supporting properties (data about bindings), searching (finding bindings given constraints on properties) and indexing (for speeding up the search on certain property names).
To accomplish the goals of the related inventions, an object name service is needed. The name service should have the following characteristics:
1. Support binding objects to names;
2. Support associating properties with an object binding;
3. Support properties per binding or properties across bindings for an object;
4. Support searching for objects based on object properties;
5. Support multilevel searches; and
6. Support indexing to permit scaling to large numbers of objects and properties.
Additionally, a distributed object name service should allow users to resolve a name when it needs to access the object. Consequently, it is important that the name space implemented by a name server not disappear even if the server which implements the name space terminates and restarts. Also, it is desirable that any mechanism that provides persistence be simple, scalable, and efficient.
An object name server must implement one or more Naming Context objects. Naming contexts offer users a mechanism to map names to objects to properties, where names are strings and properties are name value pairs. Since a context is like any other object, it can also be bound to names in a naming context. These contexts create a naming graph, which is a directed graph with nodes and labeled edges where nodes are contexts. Naming contexts offer a variety of ways to register or unregister objects and their properties, add or remove individual properties, look up properties of an object, and search for objects based on constraints on the properties. Name bindings and the properties attached to the name bindings represent the state of naming contexts. Naming contexts also allow local owned properties, shared properties, soft links, and hard links.
Systems that merely hold the name object bindings in memory implement a transient name space which disappears when the server process terminates. Such a system lacks persistence and is not acceptable. A naming system should have a relatively small storage requirement, for example, less than 5 megabytes and moderate update rates.
Although commercial databases satisfy the above criteria, engineering such a system is a major task and requires a large investment in time and money. Rather than architecting a new database which satisfies the constraints, if existing databases can be used to act as datastores, dramatic savings in time and money can be achieved.
Storing contexts as persistent objects has several drawbacks. First, the context objects must be decomposed into sub-objects in order to make some of the dynamic state persistent. Externalization stream out and stream in operations have to be provided in order to flatten and unflatten the object. Data would then have to be stored in record files. This representation makes searches based on constraints on properties extremely slow and inefficient. Updates have to be done in memory and checkpointed to disk periodically which leads to synchronization problems. It is not practical to produce good performance with such a technique, and its applicability is restricted to naming implementations with very low rate of inquiries and updates.